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Binary Labels in the Domain Name System 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1999). All Rights Reserved. 

1. Introduction and Terminology 
This document defines a "Bit-String Label" which may appear within 
domain names. This new label type compactly represents a sequence of 


"One-Bit Labels" and enables resource records to be stored at any 
bit-boundary in a binary-named section of the domain name tree. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [KWORD]. 


2. Motivation 


Binary labels are intended to efficiently solve the problem of 
storing data and delegating authority on arbitrary boundaries when 
the structure of underlying name space is most naturally represented 
in binary. 


3. Label Format 


Up to 256 One-Bit Labels can be grouped into a single Bit-String 
Label. Within a Bit-String Label the most significant or "highest 
level" bit appears first. This is unlike the ordering of DNS labels 
themselves, which has the least significant or "lowest level" label 
first. Nonetheless, this ordering seems to be the most natural and 
efficient for representing binary labels. 
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Among consecutive Bit-String Labels, the bits in the first-appearing 
label are less significant or "at a lower level" than the bits in 
subsequent Bit-String Labels, just as ASCII labels are ordered. 


3.1. Encoding 


0 1 2 
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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ 
|o 1| ELT | Count | Label 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ 


(Each tic mark represents one bit.) 


ELT 000001 binary, the six-bit extended label type [EDNSO] 
assigned to the Bit-String Label. 


Count The number of significant bits in the Label field. A Count 
value of zero indicates that 256 bits are significant. 
(Thus the null label representing the DNS root cannot be 
represented as a Bit String Label.) 


Label The bit string representing a sequence of One-Bit Labels, 
with the most significant bit first. That is, the One-Bit 
Label in position 17 in the diagram above represents a 
subdomain of the domain represented by the One-Bit Label in 
position 16, and so on. 


The Label field is padded on the right with zero to seven 
pad bits to make the entire field occupy an integral number 
of octets. These pad bits MUST be zero on transmission and 
ignored on reception. 


A sequence of bits may be split into two or more Bit-String Labels, 
but the division points have no significance and need not be 
preserved. An excessively clever server implementation might split 
Bit-String Labels so as to maximize the effectiveness of message 
compression [DNSIS]. A simpler server might divide Bit-String Labels 
at zone boundaries, if any zone boundaries happen to fall between 
One-Bit Labels. 


3.2. Textual Representation 
A Bit-String Label is represented in text -- in a zone file, for 
example -- as a <bit-spec> surrounded by the delimiters "\[" and "]". 


The <bit-spec> is either a dotted quad or a base indicator anda 
sequence of digits appropriate to that base, optionally followed by a 
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slash and a length. The base indicators are "b", "o" and "x" 
denoting base 2, 8 and 16 respectively. The length counts the 
significant bits and MUST be between 1 and 32, inclusive, after a 


dotted quad, or between 1 and 256, inclusive, after one of the other 
forms. If the length is omitted, the implicit length is 32 fora 
dotted quad or 1, 3 or 4 times the number of binary, octal or 
hexadecimal digits supplied, respectively, for the other forms. 


In augmented Backus-Naur form [ABNF], 


bit-string-label 


bit-spec 


bit-data 


dotted-quad 
decbyte 
length 
slength 
OCTDIG 


NZDIGIT 


If a <length> is present, 
be just sufficient to contain 
If there are insignificant bits in a final hexadecimal or 
they MUST be zero. 
parts even if the associated <slength> is less than 24, 
insignificant bits MUST be zero. 


<length>. 
octal digit, 


other forms, 


Loe bit-spec ny" 


bit-data [ "/" 
dotted-quad [ 


length ] 
"/" slength ] 


1*64HEXDIG 
1*860CTDIG 
1*256BIT 


Wig tt 
" O " 
Mb" 


decbyte "." decbyte "." decbyte "." decbyte 
1*3DIGIT 

NZDIGIT *2DIGIT 

NZDIGIT [ DIGIT ] 
%x30-37 

%x31-39 


the number of digits in the <bit-data> MUST 


the number of bits specified by the 


A <dotted-quad> always has all four 
but, like the 


Each number represented by a <decbyte> must be between 0 and 255, 


inclusive. 


The number represented by <length> must be between 1 and 256 


inclusive. 


The number represented by <slength> must be between 1 and 32 


inclusive. 
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When the textual form of a Bit-String Label is generated by machine, 
the length SHOULD be explicit, not implicit. 


3.2.1. Examples 
The following four textual forms represent the same Bit-String Label. 


\[b11010000011101] 
\[064072/14] 
\[xd074/14] 
\[208.116.0.0/14] 


The following represents two consecutive Bit-String Labels which 
denote the same relative point in the DNS tree as any of the above 
single Bit-String Labels. 


\[b11101] .\ [0640] 
3.3. Canonical Representation and Sort Order 


Both the wire form and the text form of binary labels have a degree 
of flexibility in their grouping into multiple consecutive Bit-String 
Labels. For generating and checking DNS signature records [DNSSEC] 
binary labels must be in a predictable form. This canonical form is 
defined as the form which has the fewest possible Bit-String Labels 
and in which all except possibly the first (least significant) label 
in any sequence of consecutive Bit-String Labels is of maximum 
length. 


For example, the canonical form of any sequence of up to 256 One-Bit 
Labels has a single Bit-String Label, and the canonical form of a 
sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of 
which the second and third contain 256 label bits. 


The canonical sort order of domain names [DNSSEC] is extended to 
encompass binary labels as follows. Sorting is still label-by-label, 
from most to least significant, where a label may now be a One-Bit 
Label or a standard (code 00) label. Any One-Bit Label sorts before 
any standard label, anda 0 bit sorts before a 1 bit. The absence of 
a label sorts before any label, as specified in [DNSSEC]. 
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For example, the following domain names are correctly sorted. 


foo.example 
\[b1].foo.example 

\ [b100] .foo.example 

\ [b101] .foo.example 
bravo.\[b10].foo.example 
alpha.foo.example 


4. Processing Rules 


A One-Bit Label never matches any other kind of label. In 
particular, the DNS labels represented by the single ASCII characters 
"0" and "1" do not match One-Bit Labels represented by the bit values 
0 and 1. 


5. Discussion 
A Count of zero in the wire-form represents a 256-bit sequence, not 
to optimize that particular case, but to make it completely 


impossible to have a zero-bit label. 


6. IANA Considerations 


This document defines one Extended Label Type, termed the Bit-String 
Label, and requests registration of the code point 000001 binary in 
the space defined by [EDNSO]. 


7. Security Considerations 


All security considerations which apply to traditional ASCII DNS 
labels apply equally to binary labels. he canonicalization and 

sorting rules of section 3.3 allow these to be addressed by DNS 

Security [DNSSEC]. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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